Recent years have witnessed increasing interest in creating and using widely accessible services, including web services implemented using representational state transfer (REST) style architectures. Unlike the heavy-weight Simple Object Access Protocol (SOAP)-based standards, RESTful services are loosely coupled and simpler to handle for developers and users alike. The large numbers of RESTful services and the simple interfaces have enabled the creation of mashups of multiple services to serve diverse purposes.
Making or forming a new composition service by combining or connecting multiple individual services, however, is time consuming and difficult due to the syntactic and semantic differences of the individual services. As a result, skilled users with programming knowledge are generally needed to build a composition of services or applications from multiple web-services. Typically, the composition of RESTful web services requires considerable programming effort. In order to get heterogeneous services to work together, skilled users must write adaptors to handle the difference in data encoding schemes (ASCII, URL, UTF-8, etc.), the conversion of formats (JSON, XML, PHP, etc.), and communication protocol differences (SOAP, REST, etc.). And, semantically relating heterogeneous services requires perhaps more significant skilled effort.
Solutions such as JOpera, and Yahoo Pipes allow programmers to use a GUI to create a workflow of services and connect the corresponding input and output attributes. However, the programmers are also required to provide adaptors required to couple pairs of services by handling the differences in terms of data encoding and formats. Moreover, such GUI based orchestration engines typically provide no hint to the developers regarding the composability of services in the first place—i.e., whether it is semantically possible to interconnect them. In such systems, developers must learn the working details of the different services to determine whether they can be used together. Another example is the BPEL4WS standard which is used for the static composition of services. This standard too does not support the discovery of possible compositions on demand.
There is ongoing research into using semantic web service languages, AI planning, rule-based plan generation, and situation calculi, for automating the composition of available services to fulfill user requirements. Despite several efforts in these areas, there is no tool that lay users without programming skills can use to generate service compositions.
Semantic and syntactic differences between services not only make it difficult to program or automate the composition of a set of services, they also make it difficult to realize that two disparate services can be used together, especially in unforeseen conditions. For example, consider a composition where the output of an MP3 encoder service is used as the input for a picture framer service. To a non-programmer, this composition does not seem to make sense and may be considered unworkable because the two services seem semantically incompatible. By considering in detail, however, the application programming interfaces (APIs) of these two services, a person that understands software would find that the MP3 encoder outputs a JPG file (among other data) that represents the artwork for the encoded sound track, and the picture framer can accept a JPG file to then frame it.
In addition to difficulties in determining whether the interfaces of two services are compatible, services, especially web services are always evolving and changing their APIs, thus potentially becoming incompatible with the applications or services that use them. Keeping track of these changes, while avoiding any coupling between services, compositions, and applications built from a particular composition is challenging.
The present disclosure provides several novel improvements to current service composition techniques, including improvements that enable lay users to connect web services easily and efficiently, without any programming knowledge.